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Status of this Memo 


This document specifies an Internet standards track protocol for the 
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improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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Abstract 


The Service Location Protocol, Version 2 (SLPv2) provides a mechanism 
for a service to be discovered in a single exchange of messages. 

This exchange of messages does not presently include any of the 
service’s attributes. This document specifies a SLPv2 extension 
which allows a User Agent (UA) to request a service’s attributes be 
included as an extension to Service Reply messages. This will 
eliminate the need for multiple round trip messages for a UA to 
acquire all service information. 
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1. Introduction 


The Service Location Protocol, Version 2 [3] provides a mechanism for 
a service to be discovered in a single exchange of messages. The UA 
sends a Service Request message and the DA or SA (as appropriate) 
sends a Service Reply message. 


It is clearly advantageous to be able to obtain all service 
information at once. The Service Location Protocol separates 
messages which obtain different classes of information. This 
extension enables an optimization to the basic exchange of messages, 
which currently does not include service attributes in Service Reply 
messages. 


This document specifies a SLPv2 extension which allows a UA to 
request that a service’s attributes be included in Service Reply 
messages. This will eliminate the need for multiple round trip 
messages for a UA to acquire all service information. 


If the DA or SA does not support the Attrlist extension, it will 
simply return a Service Reply (without the extension). Support of 
this extension is OPTIONAL. Existing implementations will ignore the 
Attrlist extension since it has been assigned a identifying number 
from the range which indicates that the receiver MUST ignore the 
extension if it is not recognized. See RFC 2608 [3]. 


If the UA receives a Service Reply message without an Attrlist 
Extension it must assume the SA or DA does not support the extension. 
In this case, the UA must send an Attribute Request for each URL it 
obtains in the Service Reply message in order to obtain the 
attributes for these services. 


1.1. Terminology 


User Agent (UA) 
A process working on the user’s behalf to establish contact 
with some service. The UA retrieves service information from 
the Service Agents or Directory Agents. 


Service Agent (SA) 
A process working on the behalf of one or more services to 
advertise the services. 


Directory Agent (DA) 


A process which collects service advertisements. There can 
only be one DA present per given host. 
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1.2. Notation Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [2]. 


2. Attribute List Extension 
The format of the Attribute List Extension is as follows: 


0) 1 2 3 
01234567890123456789012345678901 
tat —tatatatata tata tata tata tata ta tata ta ta tata tatatatattatatatat-t 

| Extension ID = 0x0002 | Next Extension Offset 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++HH 
| Offset, contd. | Service URL Length | Service URL / 
Fat — tata tat tatata to ta tata tata ta tata tatatatatatatatatatatatat—t-t 
| Attribute List Length | Attribute List / 
tat — ta tata ta—tatata tata tata tata ta tata tatatatatatatatatatatatat—t-t 
|# of AttrAuths | (if present) Attribute Authentication Blocks.../ 
tat — ta tata tota tata ti ta tata titan ta tata tatatatatatatatatatatatatat-t 


The Extension ID is 0x0002. 


The Next Extension Offset value indicates the position of the next 
extension as offset from the beginning of the SLP message. If the 
next extension offset value is 0, there are no more extensions in the 
message. 


A UA sends an Attribute List Extension with a Service Request. The 
Service URL Length and Attribute List Length are set to 0 and the 
Service URL and Attribute List fields omitted in this case. The UA 
thereby requests that the SA or DA include an Attribute List 
Extension in its Service Reply by including such an ’empty’ Attribute 
List Extension in the Service Request. 


A SA or DA which supports the Attribute List Extension returns one 
Attribute List extension for every URL Entry in the Service Reply 
message. The order of the Attribute List Extensions SHOULD be the 
same as the URL Entries in the Service Reply. 


The Service URL [4] identifies the corresponding URL Entry. 
The Attribute List field is the entire attribute list of the service. 


These attributes must be in the same language as that indicated in 
the Service Request message. 
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If the Service Request message includes a SLP SPI string, then the 
attribute list extension MUST include an authentication block. If 
the SA or DA does not support or is unable to return an 
authentication block for the SLP SPI included in the Service Request, 
then the SA or DA MUST NOT return an Attribute List Extension. The 
format of the authentication block(s) is exactly the same as would be 
included in an Attribute Reply or Service Registration message. 


3. IANA Considerations 


IANA has assigned an extension ID number of 0x0002 for the Attribute 
List Extension. 


4. Internationalization Considerations 


The Service Location Protocol, version 2 has mechanisms for allowing 
attributes to be transmitted with explicit language tagging [6]. The 
same mechanisms are used for this protocol extension. 


5. Security Considerations 


The Service Location Protocol, version 2 has mechanisms for allowing 
authenticators to be returned with attribute lists so that UAs are 
able to verify a digital signature over the attributes they obtain. 
This same mechanism is used for this protocol extension. The 
Attribute List Extension used in conjunction with SLPv2 is no less 
secure than SLPv2 without the extension. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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